home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / std / c++ / 931 < prev    next >
Encoding:
Internet Message Format  |  1996-08-06  |  3.2 KB
  1. Path: engnews1.Eng.Sun.COM!taumet!clamage
  2. From: sjc@netcom.com (Steven Correll)
  3. Newsgroups: comp.std.c++
  4. Subject: Re: delete vs incomplete class type
  5. Date: 1 Apr 1996 22:05:07 GMT
  6. Organization: NETCOM On-line Communication Services (408 261-4700 guest)
  7. Approved: clamage@eng.sun.com (comp.std.c++)
  8. Message-ID: <sjcDp7BEy.3J4@netcom.com>
  9. References: <sjcDownA7.6FA@netcom.com> <4jcdp0$b3p@venus.mcs.com>
  10. NNTP-Posting-Host: taumet.eng.sun.com
  11. Apparently-To: comp-std-c++@uunet.uu.net
  12. Content-Length: 2338
  13. X-Lines: 47
  14. Originator: clamage@taumet
  15.  
  16. >Steven Correll (sjc@netcom.com) wrote:
  17. >>         struct x;
  18. >>         struct y;
  19. >>  
  20. >>         void
  21. >>         p(x *arg0, y *arg1)
  22. >>           {
  23. >>           delete [] arg0;
  24. >>           delete arg1;
  25. >>           }
  26. >>  
  27. >> I don't see how a compiler could avoid noticing that it hasn't a clue what
  28. >> destructor to invoke at compilation time. Is there a reason (aside from
  29. >> encouraging people to migrate to Java) not to require the compiler to
  30. >> diagnose this as an error, instead of allowing it to fault at execution
  31. >> time?
  32.  
  33. In article <4jcdp0$b3p@venus.mcs.com>, Martin J. Maney <maney@mcs.com> wrote:
  34. >So why not make this sort of thing ill-formed?  Probably so that PODS can
  35. >continue to be used, as in legacy code that has been only partially ported
  36. >to C++.  (I'm thinking here of code that's been cleaned up to compile as
  37. >C++, and use some of the features such as new/delete, but that hasn't been
  38. >redesigned as OO.  Been there, done that, and it was quite worthwhile as
  39. >an intermediate step without which the code probaly would have had to
  40. >remain in Plain C until it was abandoned.)...
  41. >
  42. >Now that you've pointed this out, I should have to agree that it would be 
  43. >very nice to see compilers diagnose this, but I wouldn't want them to 
  44. >reject such a program as ill-formed for reasons that must be obvious.  
  45. >Therefore it has to be a "quality of implementation" issue, or perhaps 
  46. >even a job for a lint++ tool, since in general one might have to examine 
  47. >files that are not normally, nor are intended to be, compiled together.
  48.  
  49. Your argument is so persuasive that I withdraw my question and ask a different
  50. one: why the silly rule that a function must be declared before it can be
  51. invoked? If C++ were rid of that rule, it would be much easier to port legacy
  52. C code which has been partly converted to C++. Of course, such code will often
  53. crash in nigh-impossible-to-debug ways, but we wouldn't want a compiler to
  54. reject such code as ill-formed; this is a "quality of implementation" issue,
  55. or perhaps a job for a lint++ tool which could, by examining source files that
  56. are not normally compiled together, determine whether or not the compiler was
  57. right when it inferred the formal argument types based on the actual argument
  58. types.
  59.  
  60. :-)
  61. -- 
  62. Steven Correll == PO Box 66625, Scotts Valley, CA 95067 == sjc@netcom.com
  63.  
  64.  
  65. [ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
  66. [ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
  67. [ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
  68. [ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
  69. [ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]
  70.